-
-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make pin rm not try to find pinned ancestors by default #3600
Conversation
548580b
to
8e15b98
Compare
@Voker57 Is this for the case where youre unpinning something 'recursively' and its pinned directly? I'm unsure the exact usecase here. |
@whyrusleeping it's for the case when you're trying to unpin something which is not directly pinned: currently, in that case ipfs checks all the pins to see if they affect the requested nodes, and that can take huge amounts of time in case of big pinned items. |
924b691
to
8f559bd
Compare
test/sharness/t0080-repo.sh
Outdated
@@ -98,7 +104,7 @@ test_expect_success "remove recursive pin, add direct" ' | |||
|
|||
test_expect_success "remove direct pin" ' | |||
echo "unpinned $HASH" >expected6 && | |||
ipfs pin rm "$HASH" >actual6 && | |||
ipfs pin rm -r=false "$HASH" >actual6 && |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This behaviour shouldnt change though, ipfs pin rm
should remove either a recursive or a direct pin
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But then there is no way to remove only recursive pins. -r will remove direct pins as well. Is that intended way for -r to behave?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not mimicing rm -r anyway, since it will not delete included pins.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that rm
is a bad model. The type of a pin does not say anything about the type of a file. In addition I image most pins are recursive and direct pins are only used in special cases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I partly take back what I said. I left another comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a good optimization, However I think we should default the explain
flag to true, so that we retain current behavior by default, and also make sure that we don't change the behavior of having ipfs pin rm
remove direct pins as well as recursive ones.
@whyrusleeping IMHO default behavior should be "do not explain", since it involves potentially extremely costly operation and chances that user needs resulting information are quite low. Trying to unpin a certain block/file? Then they should know ahead to run pin rm -e to determine pin source. My target case is unpinning already unpinned hash, and I think this is more likely to happen. |
@Voker57 Okay, you've convinced me that having do not explain be the default is the right thing to do. That feels more natural to me now |
(bumping to 0.4.7 as getting feedback on changing api behaviour will take a few days) |
Regarding code LGTM, regarding UI, I am not sure but this probably applies to current UI too. |
This very closely relates to #3796. Give me a few days to try this p.r. out and verify the current and changed behavior of of |
i don't like the change in behavior |
How to remove only recursive pins them? Technically they are completely unrelated, imo interface implying they are is misleading. |
I'm not sure, but, in my opinion there should be a way to remove a pin regardless of it's type. We should not change the default behavior in any case. Perhaps the recursive option should be removed, and replaced with a @whyrusleeping (and others) opinions? |
It's not related to PR anyways, i just changed it because I thought current behavior is not intentional and test was not clear on that. I'll remove the change if -r is indeed supposed to remove both pins. |
Without - |
1d2549c
to
97f3725
Compare
97f3725
to
b673c0d
Compare
b673c0d
to
5172e69
Compare
5172e69
to
9e39d43
Compare
9e39d43
to
9ed32d5
Compare
9ed32d5
to
05fd877
Compare
05fd877
to
7641c94
Compare
7641c94
to
166d313
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kevina is this change still relevant?
It seems to me that checking all pins when removing one pin is a bit over the top.
Also make a switch to pin rm to allow old behavior. Trying to look up pins which interfere with requested unpin can be an extremely costly operation and typically is not required by user. License: MIT Signed-off-by: Iaroslav Gridin <voker57@gmail.com>
166d313
to
1c98f6f
Compare
Appears to be already changed during some overhaul. |
This was fixed in #6311. I had no idea there was an existing PR. |
Also make a switch to pin rm to allow old behavior.
Trying to look up pins which interfere with requested unpin
can be an extremely costly operation and typically is not
required by user.